Adds a new [api].auto_expose_new_tables configuration option to control whether newly-created tables, views, sequences, and functions in the public schema are reachable through the Data API roles (anon, authenticated, service_role) without explicit GRANTs.

Why

Cloud now exposes a "Default privileges for new entities" toggle (supabase/supabase#45329). When it is off, Studio revokes the default GRANTs on public at project creation so the Data API surface is opt-in per entity. Local Supabase had no equivalent: bootstrap always installed the default GRANTs, forcing users who opted in on cloud to either keep their local schema out of sync or ship a project-specific revoke migration. This adds a first-class config.toml flag and applies the same revoke SQL Studio runs.

Migration design — tri-state field

The field is intentionally optional today so the rollout can flip the implicit default without losing track of users who made an explicit choice:

• Go: api.AutoExposeNewTables is *bool with omitempty, so unset round-trips as a missing key. NewConfig does not seed a value; ApplyApiPrivileges treats nil and true identically and runs the revoke SQL only when an explicit false is set.
• TS: api.auto_expose_new_tables is Schema.optionalKey(Schema.Boolean) with no decoding default. The single read site (start.command.ts) uses ?? true, so today's nil-as-true semantics live in one place.
• The init config.toml template ships the field commented out with a brief timeline so users discover it without having a value injected.

Implementation

Config schema

• packages/config/src/api.ts: optional boolean with timeline-bearing description.
• apps/cli-go/pkg/config/api.go: *bool with toml:",omitempty".
• apps/cli-go/pkg/config/templates/config.toml: commented-out example with the rollout timeline.

Database bootstrap

• REVOKE_DEFAULT_DATA_API_PRIVILEGES_SQL mirrors exactly what Studio runs at cloud project creation when the toggle is off (revokes select,insert,update,delete on tables, usage,select on sequences, execute on functions from anon, authenticated, service_role).
• Go (internal/db/start/start.go): new ApplyApiPrivileges runs the SQL when an explicit false is set. Called from SetupDatabase (covers v15 start, v15 reset, and v14 start via SetupLocalDatabase) and from internal/db/reset/reset.go's initDatabase (covers the v14-only reset path that bypasses SetupDatabase).
• TS (packages/stack/src/services/postgres-init.ts): the revoke block is appended to the postgres-init script only when the resolved autoExposeNewTables is false, inside the same first-init branch so db reset (which wipes the data dir) replays it.

Stack wiring (TS)

• PostgresConfig / ResolvedPostgresConfig gain autoExposeNewTables. createStack.ts defaults to true if the field is absent from the input config.
• StackBuilder.ts passes the resolved value into makePostgresInitService.
• apps/cli/src/next/commands/start/start.command.ts reads ProjectContext.rawProjectConfig.api.auto_expose_new_tables and threads it through, falling back to true when the project config or the field itself is absent.

Tests

• Go: TestApiAutoExposeNewTablesDefault (asserts the field stays nil on a fresh NewConfig), a new TestSetupDatabase case that mocks the exact statement ordering when the flag is false, refreshed TestApiDiff/detects_differences snapshot.
• TS: packages/config/src/project.unit.test.ts round-trips unset/true/false through config.toml. packages/stack/src/services/services.unit.test.ts asserts the postgres-init script contains/omits the revoke block in each flag state. Existing Stack/StackBuilder fixtures updated for the new resolved field.

Out of scope (tracked separately)

• supabase config push round-trip to the Management API
• supabase link drift detection for this field
• Pulling the value down from a linked project
• apps/docs config reference entry

Closes: CLI-1454

https://claude.ai/code/session_011pZGRjHtkxjt1iZj5LYrqq